
The NASA Academy 

of Program and Project Leadership 


AP 


HI 


ill® 


nasa 


ill 









TABLE OF CONTENTS 


ASIC liagazi 


IN THIS ISSUE 

Stories of Innocence, Stories of Experience 

by Todd Post 

FROM THE DIRECTOR'S DESK 
Something Special 
by Dr. Edward Hoffman 

LETTER FROM THE EDITOR-IN-CHIEF 

So Much Depends Upon A Pickup Truck 

by Dr. Alexander Laufer 

STORIES 

Loss and Recovery 

by Ken Schwer 

Boiling Point 

by Michael C. Jansen 

When My Name Suddenly Was “Murphy” 

by David Mitchell 

Less of Me 

by Tim Owen 

SPECIAL FEATURE: PERSONAL QUEST 

Is There A Perfect Organization? 

by Julie Schonfeld 

FEATURES 

A Big Raise, A Promotion, Or... 

by W. Scott Cameron 

Three Insights About Change 

by Terry Little 


page 3 

page 5 

page 8 

page 9 
page 13 
page 19 
page 22 

page 27 

page 33 
page 36 



ASIC Magazine 3y,« 

TABLE OF CONTENTS 


PRACTICES 

Continuous Risk Management page 38 

by Phil Sabelhaus 

INTERVIEW 

ASK Talks With Joseph Rothenberg page 40 

CONFERENCE REPORT 

Masters Forum IV, February ‘02 page 46 

by Todd Post 

LOOP 

Your Letters page 51 

REVIEW BOARD 

ASK Magazine Review Board page 52 


STAFF 

ASK Magazine Staff 


page 55 


ASIC Magazine 

IN THIS ISSUE 


Stories of Innocence, Stories of Experience 


The title above is of course an allusion to the great English poet William Blake 
and his two masterworks Songs of Innocence and Songs of Experience. As I think 
about the stories we’ve collected this issue of ASK, it seems right on the money 
to me to invoke these contrary states. 

During our lives we lose our innocence and gain experience about the world on 
myriad occasions. What do we learn about ourselves from this? Uncomfortable as 
such occasions may be when they occur, reflective practitioners will see them later 
on for what they are: terrific opportunities to learn. 

Experience may come by way of profound moments of change, or occur over 
long stretches of time by the steady accrual of small changes. A profound 
moment of change is what occurs in Ken Schwer’s gripping story “Loss and 
Recovery,” about a NASA mission that is lost only seconds after launch. 

Several of the stories are by young project managers who’ve gained their experi- 
ence when they stepped into positions of leadership. Tim Owen’s story, “Less of 
Me,” is in the same vain. So is “Boiling Point,” by Michael Jansen, and "When 
My Name Suddenly Was 'Murphy'" by David Mitchell. Ken Schwer’s story also 
shows that leaders learn much about themselves when confronted with adversity. 



Todd Post is the editor of ASK 
Magazine and works for 
EduTech Ltd. in Silver Spring, 
Maryland. He has written arti- 
cles about ASK that have 
appeared in KM Review and 
Knowledge Management 
Magazine. 

You can contact Todd at 
tpost@edutechltd.com 
and tell him what you think 
about this issue of ASK. 


How would you lead people out of a devastating failure? 


Then there is Terry Little’s “Three Insights About Change.” Here a senior proj- 
ect manager takes on a new job and relearns late in his career that change is valu- 
able because it presents us with the opportunity to learn new things about our- 
selves. As Terry Little points out, change doesn’t occur any less often as we get 
older, but a lifetime of dealing with change certainly provides us with precious 
insights of how to weather our changes better. 


Essential to being a reflective practitioner is a willingness to test one’s assump- 
tions and change what one believes with new knowledge. We find this theme 
played out in all of the stories, but I find it especially intriguing in Julie 
Schonfeld’s story “Is there a Perfect Organization?” After 12 years at NASA, she 
took a leave of absence to work at CISCO Systems in an attempt to restore some 
of the idealism she’d lost over the years at NASA. At CISCO she thought she 
would find the perfect organization. Did she? Read what she finds out and how 
it helped to get her to become excited again about working for NASA. This story 
appears in our “Special Feature: My Personal Quest.” Is it too banal to say all 
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projects are personal quests? Don't we learn something new about ourselves on 
every mission? With every team we work with? 

Hope you feel you learn something from this issue. Whether that comes by way 
of a profound moment of realization in a story, or by a steady accrual of knowl- 
edge from reading all the stories, enjoy! 

Todd Post 
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Something Special 

by Dr. Edward Hoffman 

Some of my best decisions have come from a gut feeling that tells me, “This is 
right.” They spring from ideas that I know in my heart are true and important. 
As it’s a straight shot from heart to gut, and since you can’t do anything about 
gravity, I guess that’s why they always end up in my gut. 

Well, my gut feeling about the APPL Knowledge Sharing (KS) effort is that 
something special is taking place. And it’s not just my gut. There is plenty of 
interest and excitement to go around. 



Communities of Practice 

We have received numerous requests for members of the KS Team to give pre- 
sentations about what we’re doing. A recent Knowledge Management 
Roundtable at NASA Headquarters drew record-setting attendance for the event. 
A few weeks later, I was invited to give a presentation for the Census Bureau. Ron 
Taylor, a senior leader of the organization, had requested the presentation. I was 
looking forward to a group of about 20 people or so. As it turned out, the audi- 
torium was packed. Nearly 300 people were in attendance. They were excited 
about what we’re doing and wanted to pick my brain as to how they could estab- 
lish something like our KS effort in their organization. 


Dr. Edward Hoffman is 

Director of the NASA Academy 
of Program and Project 
Leadership. He is responsible 
for the development of program 
and project leaders and teams 
within NASA. Dr. Hoffman 
develops training curricula, con- 
sulting services, research proj- 
ects and special studies in pro- 
gram and project management. 
You can contact him at 
ehoffman@hq.nasa.gov. 


I also recently had the opportunity to address 120 participants of the Navy’s 
Defense Leadership and Management Program. As part of the presentation, I 
asked the participants to generate and discuss their own success stories. I asked 
for two volunteers to share theirs with the rest of us. I listened and hoped that 
the examples would demonstrate the power and wisdom of practitioner-generat- 
ed stories. No need to worry; the stories were wonderful. My only disappoint- 
ment that day was not having enough time to hear more stories from the group. 


In My Own Backyard 

Several months back I was conducting a presentation on “What the Academy is 
Doing” to a group of project practitioners at Glenn Research Center in Ohio. In 
the middle of my discussion, a project engineer mentioned that what she really 
appreciated was ASK Magazine. She mentioned reading a story by Marty Davis of 
Goddard Space Flight Center and following up with him to gain ideas for apply- 
ing his approaches to her project. Several managers also mentioned the usefulness 
and wisdom contained in the ASK stories by their colleagues across NASA. 

As I have mentioned in the past, I am thrilled at the way KS has been received at 
Ames Research Center in California under the guidance of Claire Smith. 


“She mentioned 
reading a story by 
Marty Davis of 
Goddard Space Flight 
Center and following 
up with him to gain 
ideas for applying his 
approaches to her 
project. ” 
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Increasingly, the KS Team is focusing on Center-specific activities that have 
included workshops and visits to Kennedy Space Center, Johnson Space Center, 
Goddard, Glenn, Marshall and Ames. Interest in the effort is further underscored 
by recent information that the KS portion of the APPL website has received 
thousands of hits over the past month. Indeed, something special is going on. 

Flying with Talent 

I have always been a believer that if you want a solid measure of outcomes and 
benefits, simply look around and see who you are flying with. It’s possible to 
attract talent once or twice, but if class continues to show up at the table that 
means you are serving them the right stuff. The most amazing part of this effort 
has been the tremendous amount of NASA talent, experience and wisdom that 
appear again and again. In addition to our NASA colleagues, we have had 
increasing amounts of collaboration with leaders from external organizations like 
Proctor & Gamble, US Air Force, IDEO, AOL, and Boeing. Busy, talented peo- 
ple don’t show up just for the free food. Okay, maybe a few. 

Issue 8 May 2002 



MS 1C Magazine 

FROM THE DIRECTOR’S DESK 


The KS effort has only been going strong for a little over a year. It is probably a 
little early to tell but on the whole it feels like the best thing I've been part of in 
my twenty years at NASA. And believe me, I have had a wonderful twenty years. 
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Dr. Alexander Laufer is the 

Editor-in-Chief of ASK 
Magazine and a member of 
the Advisory Board of the 
NASA Academy of Program 
and Project Leadership. He is 
Dean of Civil Engineering at 
Technion-lsrael Institute of 
Technology. You may contact 
him at 

allaufer@askmagazine.org. 


So Much Depends Upon a Pickup Truck 

by Dr. Alexander Laufer 

In one of my early studies, I examined the factors affecting the optimal size of a 
construction crew. My list of factors was very elaborate, and included worker’s 
experience, foreman’s training, complexity of work, and many others. 

I collected data via field interviews and on-site productivity measurements both 
in Texas and Israel. However, only after I completed collecting my data did I 
learn that I failed to include one simple but sometimes very crucial factor. It 
turned out that for some trades in Israel, the deciding factor for the size of the 
construction crew was no more nor less than the size of the pickup truck carry- 
ing the workers from their remote villages to the site. Literature surveys and 
field pre-testing of the interview guide were insufficient. Deep acquaintance 
with the phenomena under study is the key. 

Only when the researcher acquires a rich and intimate knowledge of the sub- 
ject, or when the practitioner serves as an active partner in helping the 
researcher formulate the right questions and design the right research tools, will 
any of us learn something meaningful. 
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Loss and Recovery 

by Ken Schwer 

As I stood harnessed in the bucket truck above the Taurus launch vehicle three 
days before launch, all the difficulties, successes, and memories of this mission 
came to mind. 

I had the privilege of being the project manager on the Quick Total Ozone 
Mapping Spectrometer (QuikTOMS) Mission. After a lot of hard work and ded- 
ication, our team had the mission ready for launch in less than two years. This 
project was started during the height of NASA’s Faster, Better, Cheaper (FBC) 
era. Besides the normal difficulties of developing a mission under FBC condi- 
tions, we were working under an increasingly risk-averse environment due to 
recent Mars mission failures. This made things even more stressful than they 
already can be on an FBC project. 

Getting QuikTOMS through its final hurdles was especially difficult. Our most 
recent troubles involved getting everybody in place for the launch, scheduled to 
occur just 10 days after the 9/11 tragedy. There were flight cancellations, doubts 
as to whether the launch would occur as planned, and the obvious anxiety of 
traveling by air to the launch site. With the help of NASA planes, charter flights, 
and communication networks, we were all in place the Monday before our Friday 
launch. So with just 3 days before launch and after a very successful Flight 
Readiness Review, I felt we were ready with our contingency plans in place. 

Loss 

There were no plans or work-arounds for what occurred just a few minutes after 
launch. Eighty-three seconds off the pad the Taurus launch vehicle had an in- 
flight anomaly that caused the vehicle to veer off course. Taurus tried to correct 
herself but she had lost too much velocity. Our concerns grew as we neared sep- 
aration from the launch vehicle. Separation went as planned and we had all 
ground resources up trying to locate our spacecraft. However, after separation, we 
never heard from QuikTOMS again. 



Ken Schwer is currently the 
Project Manager of Solar 
Dynamics Observatory at the 
Goddard Space Flight Center 
(GSFC). During his tenure at 
NASA, he has worked as the 
Observatory Manager and 
Lead Manager for the Quick 
Scatterometer (QuikSCAT) 
Mission. His other assign- 
ments have included the 
Hubble Space Telescope First 
Servicing Mission and the 
Geostationary Operational 
Environmental Satellite 
(GOES). While at GSFC, Mr. 
Schwer has been honored for 
his work on several occasions. 
These honors include the 
Aviation Week Laurel Award 
and the NASA Exceptional 
Achievement Medal for 
QuikSCAT. 


After a hectic few minutes, the informal word was that the launch vehicle never 
reached orbit, meaning the spacecraft returned to Earth after separation. The 
data revealed three pieces came down in the Indian Ocean. As I drove over to 
where the QuikTOMS team was monitoring the launch, I couldn’t help but 
think that the last two years were all a waste. 


When I walked into the building, I saw tears in people’s eyes and many on the 
team seemed lost. Our NASA Headquarters teammates did an outstanding job 
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informing management and preparing press briefings. As I tried to cope and 
understand the loss, I realized my team was carefully watching and listening to 
all my actions. Over the next few hours, we talked, made phone calls, and tried 
to further understand what had happened to the launch vehicle. Several managers 
tried to comfort the team by saying, “its not your fault, our industry is risky, and 
some things are out of our control.” Since the team was still grieving, this had lit- 
tle effect. 


“ As I tried to cope and 
understand the loss, I 
realized my team was 
carefully watching 
and listening to all my 
actions. ” 


On my Saturday flight home, I knew that I had to quickly help my team through 
the loss. Of course there were no procedures or lessons learned for this situation. 
What can you do to console people who have just dedicated two years of their 
lives on a project and then watched it fall to pieces in all of 83 seconds? And how 
do I, a young project manager, younger by many years in some cases than my 
teammates, lead them out of this wilderness of grief? 

[ wrote the following memo in the early hours of Monday when I returned to 
work. Since people were still scattered throughout the country, I elected to e-mail 
it to the entire QuikTOMS Team and upper management. 


”1 know it feels like we lost a friend. Friday evening as I went thru my 
QuikTOMS Mission Operations information, I felt lost and had great difficulty 
with the finality of our Observatory’s fate. She never got a chance to show her 
true colors in orbit. I kept thinking, “what a waste for all” but that didn't last for 
long. Once I realized all the triumphs, lessons learned, and working relationships 
created on this small but important mission, the purpose of QuikTOMS started 
to become clear. 


“I saw the telemetry stop after separation and unfortunately that was the last we 
heard of our Observatory. Our Mission Operations & Ground System team used 
every resource available in an attempt to establish contact with QuikTOMS. Our 
Taurus team should also be proud. Taurus-6 was a sight to be seen on the pad as 
she was flying the American Flag. Even after the in-flight anomaly, Taurus showed 
her strength & control by trying to correct her course. Taurus completed the 
sequence of events but did not have enough speed to get us into orbit. I want to 
thank our Taurus friends for their hard work and dedication. With the experience 
and strength of the Taurus team, I know they will rebound even stronger. 

“I truly want to thank all of you and your families for the tremendous effort, ded- 
ication, and personal sacrifices you gave to the QuikTOMS mission. Many of 
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you went way beyond the call of duty. I know this week will be difficult, espe- 
cially for our Mission Operations team, so reflect on our journey and realize the 
QuikTOMS Mission was not meant to be that of science, it was a mission for 
human will and teamwork. 


“All of you moved a mountain for me and I am forever grateful. 



The largest-ever ozone hole, roughly three times the si 2 e of the U.S., 


was detected on September 6. 2000 by NASA's Total Ozone Mapping 
Spectrometer (TOMS). The TOMS mission discussed in Ken Schwer’s 
Story ■Loss -,nd R-mv-ry" would likely have expanded our understand- 
ing of the Earth’s ozone. 


Recovery 

I received many encouraging responses from my teammates. They thanked me 
for sending this note and not forgetting about the human factor in our project. 
A spirit of cooperation guided the negotiations during contract closeouts. The 
we-don’t-want-to-work-with-each-other-again approach gave way to teamwork 
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Question 


In high-risk projects, can a 
team work together passionate- 
ly and still be resigned to failure 
in the event of that happening 
unexpectedly? 
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and fairness. All of this led to an all hands “wake party” where Center manage- 
ment expressed their appreciation and thanks to the team. I want to pass on the 
kind words from the Director of Flight Projects at Goddard Space Flight Center! 

“The reason that QuikTOMS was ‘quick’ is that the team worked exceptionally 
hard to get the spacecraft ready in two years. On top of the normal challenges, 
the QuikTOMS team was thrown the curve caused by the Mars failures, result- 
ing in a huge amount of unplanned work! Red Team, parts analysis and testing, 
etc. It was only by extra hard work, near round the clock in the last few months, 
that the Project remained ‘quick.’ Under those circumstances it is particularly 
devastating to have nothing to show for all that work. We are reminded that 
although the rewards for our work are high, risk is high. The spacecraft was lost, 
but not everything was lost. Relationships built over the past two years will 
remain ever strong in the future and will be important in future projects and col- 
laborations. Knowledge gained in teamwork and spacecraft development will be 
the springboard for future successes and career growth. Please join me in offering 
condolences to the QuikTOMS team, but also congratulations for a fantastic job, 
well done.” 

We all know where the money goes on a project, but we often forget there is a 
face and family behind every dollar we spend. The loss of QuikTOMS hurt and 
jeopardized the uninterrupted monitoring of ozone. However, the loss of good 
people in our industry would have impacted our future missions. Even though 
we can’t recover QuikTOMS from the ocean, as asked to me by my kids, we 
recovered from our loss with lasting relationships and a strong feeling of success. 

Lessons 

• Leaders lead by showing their humanity to the team. When the whole team is hurt 
or grieving, perhaps the strongest thing a leader can do is to express his or her pain 
and grief with them. 

• Never forget that missions are made up of the people who accomplish them. Honor 
the experience of working together to achieve a goal as much as you do the accom- 
plishment of the goal. 
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Boiling Point 

by Michael C. Jansen 

One of my first experiences as a journeyman engineer paralleled Dickens’ A Tale 
of Two Cities. It was the best of times; it was the worst of times. Not quite six 
months after I came on-board permanently, the Shuttle Challenger exploded 73 
seconds into mission 51L. Never have I experienced such a period of unified pur- 
pose and unhesitating professional cooperation across organizational boundaries 
as I did during our activities following this tragic event--not since has the subject 
of work been so grim. 

As did many of my colleagues in Engineering, I doggedly threw myself into the 
piece of the accident investigation assigned to me. From the long-range photo 
and film footage, it was evident that a spurious plume had emanated from one of 
the solid rocket boosters (SRB), beginning roughly a minute into the flight. The 
visual data was backed by telemetered data that showed SRB nozzle gimbal angles 
changing to adjust for the slight loss of thrust in the affected booster. Judging by 
the ensuing glow, the plume had apparently impinged upon the External Tank 
(ET), fairly near its lower dome. From the telemetry data received up to the time 
of the explosion, the propulsion team ascertained that the ullage pressure in the 
ET’s hydrogen tank, upon which the plume seemed to be impinging, began to 
drop shortly after the glow was first visible in the film footage. This was an indi- 
cation that the tank might have been breached, which spawned the theory that 
the liquid hydrogen therein ignited explosively, thereby triggering the 
Challenger’s destruction. Analysis was required to confirm or disprove this sup- 
position, and, along with the above scanty information, I was given the task of 
supplying that proof. 



Michael C. Jansen was 

recently named the Technical 
Assistant to the Assistant 
Business Manager for 
Assessments within the 
International Space Station 
Program's Business 
Management Office. This is his 
fourth story to appear in ASK. 
Others were published in 
Volumes 1 , 2, and 5. 


Problem was, I had an extremely limited background in this (indeed, any) type 
of thermal analysis, which was considerably complicated by our gaps in knowl- 
edge. The spurious plume’s heat flux level was unknown. The exact location of 
the plume’s impingement point was unknown, which meant that the geometry of 
the affected portion of the tank wall could only be guessed at. The analysis had 
to account for the presence of a cryogenic liquid on the inside of the tank wall, 
which surely would begin to boil locally, with who knew what impact on the heat 
transfer away from the tank wall. And, most hindering, I knew absolutely noth- 
ing about heat transfer in boiling liquids. 


As it turned out upon some quick research in our tech library, few people in the 
world did, and when it came to cryogenic boiling, the number of experts was in 
the single-digit category. Hmmm. But there, amid the handful of Russian names 
in the literature, was one American and his academic affiliation was with a local 
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“ He returned my call 
almost immediately 
and showed great 
interest in the situa- 
tion: Was I investigat- 
ing the Challenger 
accident? 55 


university! I couldn’t believe my good fortune! After obtaining permission to con- 
tact a non-NASA source as part of what we were supposed to treat as a secure 
investigation, I called this professor’s office immediately to set up an appoint- 
ment to get some valuable guidance on how to approach my problem. He 
returned my call almost immediately and showed great interest in the situation! 
Was I investigating the Challenger accident? I told him we at NASA were under 
orders to treat all circumstances of the investigation as confidential, and that I 
could therefore not answer that (which, of course gave him his answer). He 
agreed immediately to a meeting. 


If it walks like a duck and quacks like a duck, don’t try to tell me it’s a moose! 

My first indication that I was in for a difficult meeting came when I walked into 
the professor’s office and was greeted not only by this world-class expert, but by one 
of his visiting Soviet colleagues as well. This being the pre-detente era, when the 
Soviets were actively “borrowing” our technology to develop their own Space 
Shuttle system, and considering the confidential nature of the investigation I was a 
part of, the man’s presence made me quite uncomfortable. The professor, perhaps 
instinctively reacting to my obvious youth and his role as learned advisor, immedi- 
ately justified his colleague’s inclusion in our meeting as a means of getting anoth- 
er expert to consider the technical problem in order to bring this serious situation 
to a rapid conclusion. Certainly I had no objections, right? Fresh from college, I 
allowed myself to fall into the professor-student relationship and acquiesced. 


He wasted no time in resuming his questioning: This was part of the Challenger 
investigation, right? My attempts to deflect the question only strengthened his 
conviction that he was correct. His excitement was palpable! So, what are the 
details of the problem? I explained that I was interested in calculating the heat 
transfer away from an aluminum wall that had a heat source on one side and liq- 
uid hydrogen on the other. What type of aluminum? I didn’t know, but could 
find out. What local wall thickness? Not sure, the heat source impingement point 
was only grossly estimable, and the local geometry changes dramatically in that 
region. What was the heat flux to the wall? Don't know; the engineers estimat- 
ing that hadn't yet released any numbers. What is the inner wall surface rough- 
ness? Don’t know; I could perhaps estimate it based on manufacturing specifica- 
tions. Size and distribution of bubbles coming off the inner wall? How would I 
know that? Number and depth of nucleation sites? Huh?? 


What do you know? 
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Well, not much— that's why I came to you for help on how to approach this prob- 
lem. 


The professor, obviously disgusted, rattled off the myriad variables that estima- 
tion of the heat transfer coefficient depended on, all of which were important, 
and none of which I seemed to know. I asked whether the general approach 
couldn’t be outlined, with best guesses and available data to be inserted later to 
arrive at a good ballpark number? He scoffed, smirked at his Russian counterpart, 
and told me the problem could not be solved without knowing the variables he 
had laid out for me. Then the professor, in one of the more open displays of con- 
descension I’ve witnessed, told me in essence to come back again when I knew 
what the heck I was talking about, or send someone else more experienced who 
might have a better handle on the problem. 

I fumed during the entire 45-minute drive back to my office. 

Seat-of-the-pants engineering. . . 

Bruised ego notwithstanding, I still had a problem to solve. I returned to the ref- 
erence books I had borrowed from the library and reevaluated the information to 
be gleaned therefrom. The problem that had caused me to seek assistance to 
begin with was that no single boiling point curve (in essence, a representation of 
how quickly heat could be carried away from a surface by a boiling liquid) exist- 
ed for cryogens. Myriad empirical formula existed, each typically valid for only a 
narrow temperature range, specific surface material, surface finish, etc.; all of 
them sported the alphabet soup of variables for which I had no estimates. 


He scoffed, smirked 
at his Russian coun- 
terpart, and told me 
the problem could not 
be solved without 
knowing the variable 
he had laid out for 


Well, if there was no single cryogenic boiling curve to suit my situation, I’d piece 
together one of my own. Several sheets of log paper later, I had in front of me an 
approximation of a hydrogen boiling curve spanning the gamut of temperature 
differences ever tested in the history of cryogenic research. Considering the 
incredible scatter in the empirical data I had synthesized to form my curve, I had 
no idea whatsoever if I was in the same universe with reality, but I had my start- 
point. I just needed to test it, but how? The team working on an estimate of the 
plume-induced heat-flux to the ET weren’t quite ready with a heating range, and 
the kind of testing I had in mind wouldn’t be safe to do with liquid hydrogen 
anyway. Ah, but of course: inert liquid nitrogen! I quickly repeated my kludge- 
work, this time to approximate nitrogen’s boiling curve. 
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I consulted a friend of mine in the thermal analysis area and together we designed 
a test setup that included simple open-top aluminum box (of the same aluminum 
as the E.T.... I had researched the materials). We had the techs build and instru- 
ment several such tanks with thermocouples radiating from a central target zone 
on one side. We then set up a calorimeter-instrumented target and measured the 
heat flux from a blowtorch at various distances along a centerline perpendicular 
to the calorimeter’s face. My friend then developed a simple two-dimensional 
conduction model of the tank’s face and made predictions, using my nitrogen 
boiling curve, of the time it would take to melt the tank’s wall at the various heat 
flux levels for which we had blowtorch distance data. Following a test plan scrib- 
bled on a sheet from an engineering pad, we had the techs fill the first tank with 
liquid nitrogen and position the blowtorch at the closest (highest incident heat- 
ing) position. Then, with a roomful of bemused older techs watching and our 
cauldron bubbling over with nitrogen fog, I signaled one of them to fire up the 
torch, the signal for my friend to click the stopwatch 

“Time!” I yelled at the first sign of nitrogen pouring from the new penetration 
into the overflow basin. 

And the answer is... 

“8.6 seconds!” answered my friend, even as the tech shut down the torch. 

“What was the prediction?” Dared I hope? The actual time had sounded fairly 
familiar. . . 

After the moment it took my friend to search our handwritten matrix, the techs’ 
grins changed purpose and broadened. 

“8.8 seconds!” 

We repeated the process several times for various torch distances; in each case the 
experimental burn-through time matched our prediction to within ten per cent. 
Later plots of the thermocouple data revealed that we had also matched the wall 
temperature time- histories very well, not just the time needed to reach the alu- 
minum’s melting point. Having validated my nitrogen boiling curve and my 
friend’s two-dimensional wall model, we set our sights on the real problem at hand. 

Working from the plume team’s estimates on where the jet was impinging on the 
ET, my friend developed two- and three-dimensional thermal conduction models 
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of the local ET wall geometry. Since the models’ thermal responses turned out to 
be only negligibly different, we felt that the validation provided by our test results 
could be extended to our three-dimensional approach as well. From that point 
onward it was a mere matter of plugging in my hydrogen boiling curve, making a 
burn-through prediction based on the plume team’s estimated time-varying inci- 
dent heating rates, and comparing our prediction against the flight data. 

Our prediction matched within four percent. 





Question 


In situations like the one in this 
story, is it better to try solving a 
problem without an expert's 
help, or is it better to try and 
collect more data and visit the 
expert one more time? 
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Epilogue 

The hypothesis that the ET’s liquid hydrogen tank initiated the Challenger’s 
explosion turned out to be false. (The plume was determined to have melted the 
booster’s aft attach strut, which allowed the booster to rotate about its forward 
strut and puncture the ET’s liquid oxygen tank, which resulted in the initial 
explosion.) Nevertheless, the plume’s penetration of the ET’s aft dome was con- 
firmed by our analysis, which added to our understanding of the events that tran- 
spired during this tragic disaster. 

I took away from the experience a great appreciation for the ability of a group of 
focused, committed people to accomplish seemingly miraculous results within 
extremely short timeframes, with a minimum of information to go on. I also 
acquired a healthy skepticism for the infallibility of theoretical experts, coupled with 
new confidence in the ability of common-sense engineering to produce usable 
results even in the absence of all the data one would normally like to have. However, 
don’t take this to mean that I think engineers are better equipped than theoretical 
experts to address such problems as the one described in my story here. “Experts” 
can seldom give useful answers to unexpected questions without an opportunity for 
study, and it is rare that they will volunteer to put aside their own work to study 
“your” problem. Unless we are willing to fund them for an extended period, their 
advice must be used judiciously, and primarily in a review capacity. 

Still, in a pinch the back of the envelope can work quite well. 

Lesson: 

• Don’t be buffaloed by experts and elites. Experts often possess more data than judg- 
ment. Elites can become so inbred that they produce hemophiliacs who bleed to 
death as soon as they are nicked by the real world 
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When My Name Suddenly Was “Murphy” 

by David Mitchell 

The 1995 - '96 timeframe was a busy period for NASA's Delta II missions. Several 
spacecraft were slated for launch. During one particularly crazy stretch, four sep- 
arate missions were launched within four months, and we had to jump between 
launch bases on both coasts (Cape Canaveral and Vandenberg Air Force Bases) . 

I was the Launch Services Manager. My job consisted of the traditional respon- 
sibilities that go with a fixed price contract: managing schedule and budget, and 
overseeing the delivery of launch vehicles. The final step in each mission was, of 
course, the launch. The Project Manager traditionally led the team through the 
final two weeks at the launch base. 

My Project Manager took it upon himself to push me out into territory that I had 
never experienced before. For example, he had me plan the launch campaigns 
(manpower, resources, durations), lead some of the launch vehicle reviews, pres- 
ent launch vehicle readiness statuses to Center Management at Goddard and JPL, 
conduct pre- and post-launch press conferences, and be a part of the launch 
readiness “go/no-go” polls. 

However, he did not just throw me out to sink or swim. He hammered away at 
me to make sure I was thoroughly prepared. An example of this was when he 
assembled a panel of three people to hear a dry run of my first pre-launch press 
conference. His panel of mock reporters fired away at me with a series of ques- 
tions to make sure I was quick on my feet in responding to some very good and 
sometimes “off the wall” questions 



David Mitchell is the Deputy 
Program Manager of the 
Geostationary Operational 
Environmental Satellite 
(GOES) Program at NASA's 
Goddard Space Flight Center. 
The GOES Program is respon- 
sible for the design, assembly, 
integration, test, launch, and 
on-orbit checkout of the GOES 
weather satellites for the 
National Oceanic and 
Atmospheric Administration 
(NOAA). Prior to his work on 
GOES, he concentrated on 
expendable launch vehicle 
programs. Mr. Mitchell joined 
NASA in 1987. 


As with every mission, we always had to wrestle with late breaking launch vehi- 
cle issues. In the case of the Mars Global Surveyor and Mars Pathfinder, two high 
profile missions, that included a lot of scrutiny from senior management. In the 
past I might be associated with the senior managers through a photo opportuni- 
ty (i . e . , award ceremony) or an “All Hands” meeting. Now my project manager 
had me briefing some of these individuals on a weekly basis. 

This was both an exciting and nerve wracking time for me. My project manag- 
er's confidence in me was a great motivator and I learned a lot about addressing 
and solving issues from the technical, programmatic, and political perspectives. 
Still, it all seemed to be going rather smoothly, until the unexpected occurred. 


We were finishing our launch campaigns for '95/'96 with great success, leading 
into the last mission, Mars Pathfinder, in December 1996. Just one day before 
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launch, I received a call from my project manager who said he’d been incapaci- 
tated and would not be able to make the launch. It turned out that he had suf- 
fered a heart attack. He said he had all the confidence in me and wished me the 
“best of luck in tomorrow's launch. ” 

Although our deputy project manager and other senior managers had now con- 
verged on the launch site in preparation for the following day’s launch, the deci- 
sion was made to put me in the role of NASA Launch Vehicle Manager (LVM) for 
the next day’s launch attempt. Fortunately, and by design, I had participated in 
many launch simulations and previous launches sitting next to my project man- 
ager observing his methods and actions as the NASA LVM. Now I was the person 
giving the launch vehicle readiness go/no-go to the NASA Launch Manager. 

Had my project manager not prepared me as he did, it would have been quite 
daunting for me to be thrust into the limelight just a day before one of NASA's 
highest profile missions. In the end, the preparation was good, and everything 
went off smoothly. 

You can never know when the unexpected will occur. And anybody who is inti- 
mately familiar with “Murphy’s Law” knows that the unexpected is going to 
occur at the worst possible time. My project manager wanted me to be as ready 
as possible in case Murphy reared its head. The bottom line is there is no better 
way to be prepared than by experiential learning. 

My project manager taught me a valuable lesson. You prepare your people by giv- 
ing them many different tasks, including tasks that are traditionally reserved for 
you or other senior people. I was motivated to accept the challenge fate tossed my 
way, but not just because I had trained for it. My project manager’s confidence in 
me brought out my confidence in myself. It motivates the heck out of people when 
you show them your confidence by giving them increasingly more responsibilities. 

Lessons 

• Learning by doing expedites doing something well. 

• Your trust in people whom you feel are potential leaders brings out their con- 
fidence. Tell them that they 're doing a good job and that you have confidence 
in them and they will generally become self motivated and exhibit a greater 
degree of confidence in themselves. 
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“ My project manager’s 
confidence in me was 
a great motivator and 
I learned a lot about 
addressing and solv- 
ing issues from the 
technical, program- 
matic, and political 
perspectives. ” 
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management 


Convey that you expect much from people, and the chances are you will get 
much from them. 


Question 


Looking back at your career, do 
you agree that taking on a vari- 
ety of responsibilities has 
enhanced your performance? 


David Mitchell was launch manager on Delta II missions. Pictured here, 
the Mars Pathfinder begins its journey with liftoff atop a Delta II expend 
able launch vehicle. 



Tim Owen is currently the 
Project Manager within the 
Transportation Directorate at 
Marshall Space Flight Center 
for the Expendable Launch 
Vehicle program. He has 
worked with NASA at Marshall 
Space Flight Center for over 
1 2 years in a number of differ- 
ent positions and organiza- 
tions. He most recently served 
as the Project Manager for a 
space station experiment 
called the Dynamically 
Controlled Protein Crystal 
Growth (DCPCG) within the 
Microgravity Sciences and 
Applications Department of the 
Science Directorate. 
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Less of Me 

by Tim Owen 

Let's be frank, things just weren't working out. The project was a microgravity 
experiment that was supposed to be ready for launch in August 2000. Right from 
the get-go the hardware development team was behind schedule and over budget. 

The Principal Investigator (PI) and his science team had been responsible for not 
only the science but also the hardware development. This was one of the first 
projects coming out of the Microgravity office at NASA's Marshall Space Flight 
Center to use the PI mode for the bulk of the project management. "Thank you 
very much for the money. Please leave us alone." That about summed up their 
relationship with NASA. 

My management asked me to step in and get a handle on the project. On the NASA 
end of things, we'd been relatively hands off until now. The culture at Marshall is 
steeped in systems engineering, and what we had set off to do on this project was 
180 degrees opposite of that. Now we were trying to get back in the picture. The 
way my management put it to me was like this: "You've got to— you know— roll up 
your sleeves and get down in there. Take back control. You're our guy." 

I came on as the project manager for NASA in the fall of 1999. In the winter of 
2000 initial verification testing began. Right off the bat one of the key technolo- 
gies was failing. The PI needed to capture digital snapshots of the crystal growth 
process in order to understand and determine the physics of crystal growth as it 
occurs in a microgravity environment. Clarity of resolution was required at two 
different points on the crystal growth chambers: one for capturing the digital 
images, and the other for measuring the laser light scattering ratio. In the case of 
the latter, the resolution of the laser light scattering ratio was not meeting the sci- 
ence requirements. 

Such were the kinds of technical problems I was expected to get a handle on. 
There were other problems beyond the hardware developer's control. Defining 
hardware requirements, in particular hardware interfaces, was complicated by the 
fact that the development of the vehicle (Space Station) and carrier (EXPRESS 
rack) was taking place concurrently with the development of this experiment. 

If all this doesn't sound like enough high drama, it was my first assignment as a 
project manager. Naturally, I wanted to prove myself and be successful. I also 
wanted to do right by NASA and live up to the example set for me by the best 
project managers I had worked for during my twelve years at Marshall Space 
Flight Center. 
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Sometimes d^suibed as "weightlessness," microgravity is a condition in 
which the effects of gravity are greatly reduced. In microgravity, researchers 
can isolate and study the influence of gravity on physical processes, such as 
the flame shown here. 


Bull in the China Shop 

It's a precarious situation to be in when you start off riding one horse across a 
river and decide in the middle to get on another. The hardware development 
team was confused at first, and not exactly amenable to this new arrangement. 
They felt like they had been empowered to go do this job and now NASA was 
telling them, "Look, you're not meeting your cost and schedule commitments. 
We're going to have to step up our involvement." 

Suddenly their relationship with NASA, including our level of technical involve- 
ment, had changed in quite a dramatic way, in part because we were entering the 
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testing and verification phase but primarily because of their poor performance. 
There's no way you can change from one way of working together to another 
without somebody on their side wondering, "What's going on here? Am I doing 
something wrong?" 


“ Funny how natural 
tendencies, despite 
training to the con- 
trary, can undo our 
best intentions. ” 


Part of the problem was me, too. When I see that something is not going well, I 
have a tendency to push everyone out of the way and take charge. Maybe that's 
why my management thought I was the person to step in and take hold of the 
reins on this project. I had been through enough project management training to 
know the value of consensus building and the need to establish good communi- 
cation across the team. Funny how natural tendencies, despite training to the 
contrary, can undo our best intentions. Given the state of the project, the pres- 
sure I felt under, it was hard not to succumb to the urge to overcontrol. 

My objective was to stay focused on results. Schedules, deliverables. Did we pass 
that verification item, or did we fail? If we failed, what do we have to do to get back 
in line? We had some very long meetings, and there were painful discussions. In 
order to focus them on cost and schedule performance, we started each meeting 
with a schedule review. The schedule was generally about six pages long with maybe 
a dozen items on each page. As we worked through that, it became obvious to me 
that the hardware development team did not have a solid understanding of what 
was on their schedule and how it impacted other parts of the project. A lot of my 
questions started to sound the same: "Tell me what you mean by this activity." 


It was rough on them because they were seeing that they really didn't know what 
their drivers were. Not surprisingly, they developed something of a defensive pos- 
ture to me. I asked hard questions. A lot of these folks on the hardware develop- 
ment team had been going along and never been held accountable. I came in and 
one of the first things I did was say, "Let's look at who the people are on the proj- 
ect, what their responsibilities are, and hold each person accountable for what 
they're supposed to be doing.” 


Was it wrong to ask hard questions? Certainly not. But just like the impact of a 
joke depends so much on its delivery, so does the ability of a leader to effective- 
ly communicate where the team is going. My approach rubbed some people the 
wrong way. Feelings were hurt. The tone I was conveying, and none too subtly, 
was that you all are screwups and I'm here to fix things. 
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Learning What I Already Knew 

Part of establishing accountability, and being a good project manager, is learning to 
work with your team. Because every project team is only as good as the weakest link. 

I realized soon enough that I could not do everyone's position. Who knows how 
long I might have kept pushing had I not recalled a similar situation on a proj- 
ect about six years earlier? At the time I was working as a subsystems lead and 
there were some computer sequences that needed to be completed by a certain 
time. I had a particular understanding of how I thought it ought to be done, and 
when I gave the job to the person who was going to do it I said, "Have this ready 
in three weeks, and this is how I want it done." To his credit, he said to me, 
"Look, if you've given me the responsibility and you've empowered me to go do 
this, then let me do it the way I think it ought to be done." 


‘Look, if you’ve given 
me the responsibility 
and you’ve empow- 
ered me to go do this, 
then let me do it the 
way I think it ought to 
be done.’” 


That was a profound realization for me. You could even call it a "Eureka" 
moment. At that point I recalled working under project managers whom I con- 
sidered to be the best. The ones who were the best examples, my mentors, gave 
me the authority to go off and do the job my way. Because they gave me that 
authority, I felt accountable to them and to the project. 


Eventually, the guy assigned to the computer sequences worked out the problem, 
and I was glad in the end that it was not done in the way I wanted. I was able to 
see the merits of what that person was doing, and this opened up my eyes to real- 
izing that I was not alone on this project. Help was always there. All I needed to 
do was reach out to it instead of pushing it away. 


Here I was six years later, learning that same lesson all over again. You build your 
team by building your people. There was no doubt that people on this project 
were working hard. Clearly, they were not focused on being accountable for their 
cost and schedule, but there was never any question about whether they were 
putting in enough hours or doing enough analysis. 


There are ways of getting people to be accountable, and some strike me as far 
more favorable to the overall good of the project. Just like in any relationship, 
you have to try to understand each other's point of view. You can't say, "Go do 
this, just because I said it." It doesn't work that way. Milestones and accounta- 
bility are great, but the key is to agree upon goals. Once you do that you must 
let them work. You don't have the competencies of all the team members, and 
you don't have enough time to learn them all. 
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A perfect example dealt with the concurrent development of the science instru- 
ment with the vehicle and the carrier. This was a tremendously tedious and com- 
plicated task. It required an enormous amount of coordination between the hard- 
ware development team, vehicle and carrier development organizations and the 
responsible engineering disciplines at Marshall. By empowering and allowing the 
lead systems engineers to perform their roles made a big difference in the project 
running smoothly amidst the confusion. 


The significance of allowing the hardware development team, science team, and 
the engineering team and their discipline/element leads to do their jobs and 
know that I, the project manager, was going to let them to do their jobs, but with 
the expectation that they would do it in a timely manner and in a cost conscious 
way was so crucial to the ultimate success of this project. 


In the end, we were able to gain back some of our schedule after a major de-scope 
and launch date slips. More importantly, I learned something about myself, yet 
again, that is going to make me a better project manager. The bull-in-the-china- 
shop approach leaves little room for movement. There's only but two things left 
on the floor after the bull has had its way in a china shop, and neither one of 
them is very nice. 


When I came onto this project, I was very ambitious and very sure of how I 
thought things should be handled. This is going be a brand new project, starting 
my first day. Sorry, but it doesn't work that way. As much as I wanted to take 
hold of the reins, grab the bull by the horns, be active, "You do this; you do that," 
it's just not the right way. 

Question 

You can't force people to do what you want them to do. Instead, what you real- 

What lessons have you had to 
relearn throughout your career? 

ly want is to encourage people to take responsibility so that they're doing some- 
thing because they want to do it, not because you want them to do it. A little less 
of me in this case went a long way. 


Lessons 


• Resist the urge to micromanage. Encourage the team effort. Inclusion and openness 
work better than exclusion and arrogance. 


• Be open to team members who can approach a problem and solve it differently than 
you because of their expertise. 
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Is There A Perfect Organization? 

by Julie Schonfeld 

When I was 10 years old, I decided I was going to be the first woman astronaut. 
By the time I was 12,1 knew what schools I was going to attend, what degrees I 
was going to get; basically, I had the whole thing figured out. 

This is the way I've always been. I make a goal for myself and plan the best path 
to get there. 

In high school, I was an intern at the Kennedy Space Center. I went on to be a 
pre-co-op and a co-op student at Kennedy too, and when I graduated 1 was 
offered a position at Ames Research Center in California. 

Which is where I am now, still at NASA, the place I've always dreamed of work- 
ing, and while I'm not an astronaut, I'm fine with that. Being a project manager 
has turned out to be wonderfully challenging, and I enjoy contributing to the 
Agency that way. 

But this story is not so much about dreams as it is about the real world. A cou- 
ple of years ago I was feeling restless. After 9 years at NASA as a project manag- 
er, I felt I had reached a point in my life where I needed a change. I took a leave 
of absence to find out what it was like to be a project manager in private indus- 
try. This was not an easy decision. All I ever wanted to do was work for NASA. 
In fact, it was absolutely heart wrenching for me to leave because I was thinking 
I might not come back. 



Julie Schonfeld is currently 
the acting Deputy Project 
Manager of the IT Strategic 
Research Project. Previously 
at Ames Research Center. She 
has also worked at Ames on 
bio-instrumentation for life sci- 
ences research, including the 
Neurolab STS-90 Mission, and 
prior to that, chemical/gas 
detection systems at Kennedy 
Space Center. In July 2000, 
she took an eight-month leave 
of absence and went to work 
at Cisco Systems, and consid- 
ers this one of the most valu- 
able experiences of her career. 


My personal philosophy of project management is that you should place the 
highest value on the people doing the work, your team. I believe that the people 
doing the work know better than anyone what should be done in their individ- 
ual areas, not management. I've seen cases where project managers and upper 
managers above them will decide something on a project despite the views of 
someone who has more knowledge about the issue in question. Letting the team 
know what the goal is and giving each individual a role in that and clearly defin- 
ing what their responsibilities are and just letting them go--that's what I try to 
do as a project manager. In general, I don't find that to be the case. Too many 
managers are concerned with appearing to know more than anyone below them. 
I suppose this was the source of my dissatisfaction at NASA, and why I thought 
I needed a change. Was it like this everywhere? I needed to know. 
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The Big Leap 

Through a process of elimination, I arrived at Cisco Systems. I knew they were 
doing really exciting work there, and clearly, they were a company that could pro- 
duce. Everything that I d read in the press about them said such marvelous 
things. And then it's rated as one of the best companies to work for. 

Now, what position I was looking for at first, I didn't have a clue, but I knew I 
could offer pretty solid skills as a project manager, so I went with it. Define the 
goal, and then develop a plan that points in that direction. 

It turned out there was an opening for a Project Manager in one of their 
Information Technology (IT) design groups. I applied and was hired straight away. 


“After 9 years at 
NASA as a project 
manager, l felt I had 
reached a point in my 
life where I needed a 
change. ” 


Initially it seemed like a nice fit, and I was quite pleased. One of my goals was to see 
why Cisco was talked about in such glowing terms. I wanted to find out if it was just 
hype or if Cisco really was different. So I set out to see if they "had the goods." 

Cisco has a different take on project management than I was used to at NASA. 
They do not assume that the project manager is necessarily the technical expert 
in her group. In this particular IT group that I was part of, I was partnered with 
a network architect, and we worked together as a team. It was a partnership in 
the true sense of the word. The network architect was responsible for the techni- 
cal direction, and as the project manager I was responsible for managing the 
effort and being the interface to upper management and to other lines of busi- 
ness within the company. At the same time, I was not excluded from the techni- 
cal side of the project, and I felt that my contributions there were welcome. 


At Cisco, teams have more say than any one individual. Project teams can even 
overrule vice presidents. If a Vice President says you will do this, the project team 
can say, "Well, these are all the reasons why we think we shouldn't go in that 
direction. " Naturally you have to do more than just offer an opinion. You must 
build a case, but it is a real policy. I saw it in action several times. 


The project that I was working on dealt with video conferencing, and they want- 
ed to deploy a product immediately. We showed all of the problems that would 
occur if it were deployed too soon, and how it would prove to be unmanageable 
and unreliable. Because we could not guarantee service, we convinced them it 
was best to wait. 
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What impressed me about Cisco is that management focuses on enabling 
employees to succeed. That's why their acquisitions of other companies are so 
successful. Within two weeks, all the employees of the acquired company have 
their benefits, salary packages, and computers. The beginning-to-end transition 
process is three months. These people are not suffering, wondering what is going 
to happen to them. 

A major focus of the company is "What's good for Cisco as a whole is what's 
good for everyone." That focus makes for a constructive work environment, and 
it's within that environment that people remain enthusiastic about their jobs and 
hence maximize their productivity. That aspect of "the people element" is what I 
believe management should be about. 

Straight Down 

Now why did I return to NASA when it seems I had found my niche at Cisco? 
The reason that I left actually was because a situation developed that was incon- 
gruous with what the Cisco culture was supposed to be about, and I wasn't sure 
that they were going to live up to their reputation. 

The manager who had hired me thought our group was getting to be too large. 
He decided to break us up into three subgroups and was going to put a new layer 
of management between him and the group. We actually got to help hire this per- 
son, and in the interview he seemed fine. Well, he turned out to be someone who 
assumes that he knows more than anyone. 

He didn't respect anybody's input. The whole team would say, "We think we 
should go here," and he would say, "Well, that's fine, but I think we need to go 
here, and so we're going to do what I say." 

When I showed him a presentation, he told me what I needed to do technically 
and was clearly wrong, but wouldn't listen to me when I tried to explain. I 
watched him publicly belittling someone, and additionally, performing strong- 
armed "corrective measures" with someone who was one of the best performers 
in our group. "You will be on my calendar every single day and I'm going to 
monitor your progress daily," he told him. 

One Friday at the end of the day, many of us who were disgruntled held this 
meeting to discuss the situation, how he was micromanaging this process that we 
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Do virtual realities and perfect organizations have something in common? 
Hope it's not the dress code. 


were supposed to be developing, and what we should do. There were just a lot of 
hostile comments from everyone in the group and how this was totally incon- 
gruous to the way things were supposed to be done at Cisco. 

We went to our original boss and said he's being horrible. We expected him to 
be fired, or moved to somewhere else in the company at least, but this didn't hap- 
pen. Our original boss said, "I'm going to work with him, and we'll see about 
improving this." 
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A month later we weren't seeing any improvements. I actually went to my origi- 
nal boss's manager, and then I went to a Vice President, and I said, "There is a 
big problem. He's horrible, we re miserable, and our productivity is being affect- 
ed." I did this because John Chambers, Cisco's CEO, says in his meetings, "We 
cannot afford to have bad managers. We cannot afford to lose good employees. If 
you have a manager who's bad, you need to escalate it, you need to take it to your 
manager's manager, and if they don't address it, you take it higher." When it was 
clear that my manager wasn't going to take any action, I went higher. 

Around this same time my leave of absence was about to come up. I had to either 
go back to NASA or resign. I called and begged for a month's extension on my 
leave, and NASA said okay. At the end of the month I still wasn't seeing any 
improvements. I lost faith that Cisco was going to do anything about him, and 
so I decided to return to NASA. 

Parachute 

I was the first one to go, a month later somebody else left, and then when the 
third person quit, Cisco did what it should have done at the beginning. They 
demoted him, six months after we raised the issue. 

When I returned to NASA, I was afraid it was going to feel like I was moving 
back in with my parents after I had gone to college, but instead it turned out that 
I felt refreshed and ready to take on a new challenge, set new goals. 

I don't regret leaving. It was a huge learning experience for me, personally. A 
growth experience. I became a little wiser, a little more realistic about organiza- 
tions. None are perfect. Mostly what I wanted, I realize, was to work with really 
smart people doing really interesting work, and that's right here. Maybe I had to 
leave NASA to see that, but I'm glad for the experience I had at Cisco, and the 
renewed sense of optimism I have about my future at NASA. I'm still idealistic. 
In fact, I feel even more so now than ever. 

I'm on this crusade now to change things at NASA to the way that I think they 
ought to be. NASA's a great organization. When I compare the best people 
they've got at Cisco with who we have here at NASA, I see the same high caliber. 
Let's allow the people who are doing the work to use their intellects to do the 
best job that they can. 
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is There A Perfect Organization? (cont'd) 


A lot of it is bringing over some of what I learned about the culture at Cisco. I'm 
talking to people whenever I get a chance, advocating for some of the things I 

saw in the culture at Cisco, like individual empowerment, focusing on the team. 

Question I want to take this to people in upper management who will listen to me. 

How do you maintain the right I feel like this is my NASA, and I want to do what I can to make it what it should 

balance between realism and be. 

idealism? 

Lessons 

• Cultures do exist that respect the knowledge of practitioners and the power of team. 
They are not just artfully crafted success stories. 

• Even excellent organizations have their own limitations because people are just people. 

• Change is a great opportunity to rejuvenate oneself. When you feel frustrated with 
your situation, don't dwell on your frustration but see it as an opportunity to restore 
your idealism. 
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A Big Raise, A Promotion, Or... 

by W. Scott Cameron 

I recently got an e-mail requesting nominations for our 11th Capital 
Management Leadership and Mastery (L&M) Award program. This program rec- 
ognizes capital management practitioners in project management, construction 
management, capital purchasing, facilities engineering, design management, cap- 
ital finance, and initiative management for their functional leadership and mas- 
tery throughout their career. 

This e-mail caused me to reflect on how organizations recognize peoples' contri- 
butions in traditional (pay and promotion) and non-traditional ways (recogni- 
tion, etc.). I was fortunate to be chosen as the project manager of the first L&M 
program. As our company's Capital Management Organization matured, we dis- 
covered we had a lot of experts in various capital management functions who we 
wanted to recognize but were limited as to how to do that within our tradition- 
al pay and progression programs. Thus, the stage was set to explore new ways to 
recognize individuals and their contributions. 

A team of project managers, including myself, evaluated a number of recognition 
programs and proposed our own to recognize individuals within the disciplines 
noted above. Our objectives were clear: 



W. Scott Cameron is Capital 
Systems Manager for the Food 
& Beverage Global Business 
Unit of Procter & Gamble. He 
has been managing capital 
projects and mentoring other 
capital management practition- 
ers for the past 20 years at 
Procter & Gamble within its 
Beauty Care, Health Care, 
Food & Beverage, and Fabric 
& Home Care Businesses. 


• Establish a program where there were no winners and losers, only award recipients. 


• Get Capital Management practitioners and their hierarchy to view the program as a 
positive development. 


• Establish simple nominating criteria. Nominees had to have demonstrated sustained 
technical mastery and leadership in ways that led to significant contributions to their 
business areas. 


• Limit the number of award recipients so that getting an award would be regarded as 
something special. 

We proposed an awards luncheon where each award recipient would receive a 
plaque commemorating their achievements in front of their peers and hierarchy. 
Hierarchy agreed to this proposal. 

Thus, the process began: 


• Nominations were requested and received. 
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• Nomination Committee reviewed nominations and recommended award recipients. 

££ AS I talked to each Of • Award recipients and their hierarchy were informed of their selection. 

them, I learned how 

much it meant to be • Invitations to the luncheon and awards presentation were sent out to all practition- 
recognized by their ers. 

peers. ” 

• Luncheon and award presentation were held on schedule within cost. 

Everything was going along as planned until the day of the luncheon when some- 
thing totally caught me off guard. I knew each of the award recipients but on the 
day of the luncheon I noticed I had never seen each of them so happy in all the 
time I had known them. As I talked to each of them, I learned how much it 
meant to be recognized by their peers. 



I've attended each L&M celebration and been involved in managing other recog- 
nition events. The one thing that continually stands out in my mind in all of 
these occasions is the happiness of each individual on being recognized by his or 
her peers. 
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By being a participant in the formation of this recognition event and watching it 
flourish over the years, I feel I have had a rare opportunity to better understand 
how important it is to individuals to be recognized for their accomplishments 
throughout their careers. It is easy to become cynical about traditional and non- 
traditional rewards and recognition programs. However, as we continue to raise 
the bar on what we expect out of our project managers, we need to look for new 
and exciting ways to celebrate not only their team's successes but also their indi- 
vidual success. 




Terry Little is currently the 
head of the Air Force's Center 
for Acquisition Excellence. 
Before that he was the 
Program Director for the Joint 
Air-to-Surface Standoff Missile 
(JASSM). He is one of DoD's 
most seasoned program man- 
agers. He entered the Air 
Force in 1967 and served on 
active duty until 1975. In 1997 
he was promoted to the grade 
of SES. 
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Three Insights About Change 

by Terry Little 

Recently, I changed jobs. I moved from Eglin Air Force Base In Florida, where I 
had worked for 30 years managing programs, to a newly created job in 
Washington, D.C. as the Director of the Air Force Acquisition Center of 
Excellence (whatever that means!). This experience has led me to reflect some on 
job changes and how to adapt to them. 

Insight #1 

My first insight is that I have had to restart the process of developing my credi- 
bility. While I am well known within the Air Force as a program manager and, 
hopefully, a capable one, it is clear to me that I have to re-establish my credibil- 
ity in this new job. In other words, I cannot live on my past laurels. How do I 
get people to listen to what I have to say? More importantly, how do I get them 
to act based upon what I have to say? 

Certainly neither my position nor rank is very helpful in my new role. Lots of 
people at the Headquarters have high-sounding positions and high grades, but 
don't deliver anything other than words of caution or dissent. Many view their 
roles as keeping something bad from happening rather than helping make some- 
thing good happen. These folks have no credibility and the system merely toler- 
ates them. 

I have to prove that I can be effective here--effective not just in generating new 
ideas, but also in making them bear fruit. That's tough. It demands that I don't 
promise more than I can deliver which, in turn, infers that I should know rea- 
sonably well what I can deliver. Right now, I don't know because a lot of it 
depends upon my ability to persuade people to my way of thinking. I do have 
some confidence in my ability to persuade, but I know that results will hinge on 
my skill in getting people to buy into my agenda for change and to accept 
accountability for it. As a program manager, I never had that challenge. I had (or 
took) lots of authority to act unilaterally and my goals seemed clear. Now I have 
come to understand how fragile credibility is and that establishing and main- 
taining it is continuous. 

Insight #2 

My second insight has come from pondering over the answer I give when people 
ask me how the new job is going. My stock answer is that "It's too soon to tell." 
The real answer is "I don't know." The reason is that I still haven't grasped what 
constitutes success in this new job. Is it as simple as making my bosses happy? 
How about pleasing my customers -program managers and industry partners? 
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I am not comfortable with these measures because they imply that making peo- 
ple happy or comfortable is equivalent to doing the right thing. My experience 
tells me otherwise. Approval-seeking behaviors virtually always produce bad 
results both because (1) we never really know what will make others happy and 
(2) making others happy often hinges on telling them what they want or expect 
to hear. I am still working on this one and am fairly certain that there is no easy 
metric for this. 


Insight #3 

Third, I am finding to my surprise that my experience as a program manager is, 
on balance, a liability in my new job. The problem is my unconscious reliance on 
that experience to know what is right without taking into account that every sit- 
uation is different. No matter how well intended, one-size-fits-all approaches 
never work. The reasons are simple. Every situation is unique and thus demands 
different approaches--different than what may have worked in the past for me or 
for others. More importantly, I know the key to success is implementation, not 
strategy or approach. There are plenty of OK approaches to every problem, but 
the best one will always be the one that someone can implement well. 

For example, one of my first tasks in the new job was to totally rewrite the Air 
Force's instruction for managing acquisition programs, starting with a clean sheet 
of paper. I wrote the instruction based upon what I thought would be some guid- 
ing principles for an empowered manager; it contained no long list of "how-to" 
instructions. To my dismay, many in the field have been critical of the instruc- 
tion because they don't know how to translate guiding principles into action. 
They want more detailed guidance. What I concluded was that I wrote the 
instruction as one that I would want and didn't consider that most managers in 
our system view lack of guidance as a problem and not an opportunity. That's 
something I mean to change, but it hasn't happened yet. My experience played 
too dominant a role in my thinking. 


u Many view their roles 
as keeping something 
bad from happening 
rather than helping 
make something good 
happen. ” 


Finally, I have already confirmed what I previously thought. This change is 
healthy for me. It has re-ignited my passion and given me a new challenge that I 
never would have had where I was. Admittedly it is uncomfortable, but it is also 
exciting in a way that my previous job was not. I had done it so long that my zest 
and sense of vitality were gone. In short, I was bored and didn't even realize it. 
Three cheers for change!!! 
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Continuous Risk Management 

by Phil Sabelhaus 

Background 

Risk identification is an ongoing activity that takes place during the routine proj- 
ect workflow. Project activities such as programmatic and technical meetings, 
telecons, reviews, and other forms of communication often bring to light project 
risks. When this occurs, we record and analyze the risk on a Risk Information 
Sheet. The process outlined below helps the project team identify and cope with 
project risks throughout the life of the project. 


Procedure 


1 . T earn identifies list of potential risk items. Not all items identified are accepted. Risks 
can be current problems or potential future problems. 

2. Risk Mitigation plan with action items and due dates is developed for each accept- 
ed risk item. 

3. Team meets regularly (every 2 weeks for us) to assess risks and add new risk items, 
if necessary. See Status section on Risk Information Sheet below. 

4. Risks are closed when all the actions to close the risk have been taken. Some risk 
items are closed quickly; others are open for a long time. Some are considered 
watch items and the action plan doesn't kick in until certain negative events happen. 

5. Action plans include second sources of some items, requirements redirection, dif- 
ferent technologies, etc. 

6. Closed risks remain in the base for future learning. 

Example of a Risk Information Sheet 

see opposite page 
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Example of a Risk Information Sheet 


ID TS 001 

Risk Title Chemistry DRAM 

Identified 4/19/99 

Priority 

Statement 

Since there are a limited number of DRAM spares between the Aqua and Aura 
spacecraft and Aqua is given first priority; there may be inadequate DRAM to meet 
the two-orbit data storage requirements for the Aura Solid State Recorder (SSR) . 

Probability 

Medium 

Impact 

High 

Timeframe 

Near Term 

Submitter Name 

Class 

Assigned to 

Andrea Razzaghi 


Context 

TRW plans to meet the current two-orbit data storage requirements by augmenting the DRAM units 
reserved for Chemistry with DRAM units currently being reserved as PM spares. There are no more DRAM 
units available beyond those currently allocated for PM and Chemistry. The Common Bus SSR design is 
based on these 5.4V DRAM units (current technology is 3V). 


Mitigation Strategy 

A. Track the Usage and Attrition of DRAM 

B. Enable OMI Data Compression 

C. Challenge Data Storage Requirements 

D. Redesign SSR 


Contingency Plan and Trigger 

• Spacecraft trigger point for using mitigation B is when the amount of DRAM available for the Chemistry 
SSR is less than the amount required to meet the two orbit data storage requirements without OMI data 
compression implemented (loss than 104 Gbits). 1AM trigger point is TBD. Ground system trigger point is 
TBS. 

• Spacecraft trigger point for using mitigation strategy G is when the amount of DRAM available for the 
Chemistry SSR is less than the amount required to meet (lit! two-orbit data storage requirements with OMI 
data compression implemented (100 Gbits). 

• TRW indicates that there would be an impact to the launch date for using mitigation strategy D due to the 
immaturity (not flight qualified) or the alternative high density technology. 
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ASK Talks With Joseph Rothenberg 



Joseph Rothenberg has had a remarkable career ai NASA. In December 2001 
he retired as the Associate Administrator (AA) for Space Flight in charge of 
I Inman Exploration and Development of Space. Under liis tenure as AA, the 
International Sjwce Station began orbital assembly and human operations, a 
new Space Shuttle upgrade program was initiated, and a joint Human and 
Robotic Space Exploration Plan and Technology initiative was developed. 
Before this, he was Director of NASA's Goddard Space Flight Center. During 
his tenure as Director, he developed a new strategic plan for the Center and 
transformed Goddard from an internally focused organization to a customer 
focused one. In addition, he established a large number of new outreach activ- 
ities, including using NASA programs to help increase the math and science lit- 
eracy of America's students. Before becoming Director, he was Associate 
Director of Flight Projects for the Hubble Space Telescope at Goddard. He is 
widely recognized in the Aerospace and Space Science community for leading 
the development and execution of the highly successful first Hubble on-orbit 
servicing mission, which corrected the telescope's flawed optics, 


Long before his ascent into these high profile positions at NASA, Joseph was 
a project manager. He started at NASA during the Apollo era, and was man- 
aging his first project almost as soon as he exchanged his cap and gown fol- 
lowing college graduation for a suit and tie at the Agency. We spoke in 
February at the Fourth APPL Forum of Master Project Managers, where he 
was invited to talk about his career at NASA. 


ASK: Is there a golden age of project management at NASA? 

Rothenberg: It's an interesting question. I never thought about it as a golden 
age, but when you look at it that way, the first one probably would have to be the 
1960s with Apollo. Managing the Apollo program was the biggest challenge 
NASA had at the time. Something that large, as complex as that, with as much 
new technology as there was, clearly, that was a feather in NASA's cap. Everybody 
wanted to be a part of it, to make it succeed, so it had a tremendous priority. The 
best and the brightest were struggling to be a part of the team. If you look at the 
age of some of the key people, they were young even by today's standards for 
project managers, and in those days they were handling the largest projects in the 
country. They were managing those projects, leading them, making decisions, 
billion dollar decisions, and with great success. I think that was something 
unique to the Apollo era, it attracted the best and brightest, and it enabled a lot 
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of young people very early in their career to take on leadership roles. 


ASK: You were a project manager during the Apollo era. How were you involved 
with the program? 


Rothenberg: I was on the periphery of Apollo. I worked on the robotics side. 
Three months out of school I was managing my own little project. I could bare- 
ly spell the word 'project.' I was 24-years old, right out of school, and I was given 
my own budget, my own set of deliverables, and a team of engineers who worked 
for me, some of them twice my age. 

ASK: That must have been exciting, managing a project at 24? What were some 
of the challenges being that young and having so much responsibility? 

Rothenberg: Like anybody that age, I worried about the decisions I was mak- 
ing. I had no basis to make them on after all. I'd be doing technical calculations 
as well as managing the project, and I'd be spending a fair amount of time at 
night, just re-checking all my calculations, and still I got one out of five wrong. 
Of course I made every mistake one could make, but I was learning, and I'm still 
learning. 


“ I was 24-years old, 
right out of school, 
and I was given my 
own budget, my own 
set of deliverables, 
and a team of engi- 
neers who worked for 
me, some of them 
twice my age. ” 


ASK: One of the things Jerry Madden told me when I interviewed him for an 
earlier issue of this magazine (see issue 5) was in those days the project manager 
could hold the whole spacecraft in his head. He said now that's just impossible. 
The systems and subsystems are so complicated. 


Rothenberg: That was certainly the case for small satellites like the ones Jerry 
worked on, but you think about Apollo, and then the Sky Lab a little later, and 
then the Shuttle--I mean those were never systems that one could get your arms 
around. In fact, there's a big distinction in the role of the project manager on 
those large human space flight missions and the smaller robotic spacecraft. In 
human space flight projects, they manage the paper, the specifications, and the 
interfaces, and the contractors worry about the hardware performance. Large- 
project managers depend much more on configuration management systems and 
interface control systems to manage the end-item products. With the smaller 
robotic spacecraft, it's much more hardware and product oriented. 


ASK: Is there a difference in the kind of person you would choose to manage a 
large project as opposed to a small one? 
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ASK Talks with Joseph Rothenberq (cont’cH 


Rothenberg: In a large project, the technical skills are Important to recognize 
what's Important, but day-to-day technical decisions are made layers below him. 
The important thing is to be able to communicate to very large teams of people. 
He's much more working through other people, where the small project manag- 
er is often looked to for technical input. Not always, it depends on the individ- 
ual, but a smaller-project manager can be much more technically oriented. 

Todd: Earlier you said the 60s was NASA's first golden age of project manage- 
ment. Are there others? 


u Right now there is 
not a training ground 
for project managers 
for the next genera- 
tion of human space 
flight programs. ” 


Rothenberg: Oh, I think the 90s could be called a golden era, and I don't mean 
that because it was the Dan Goldin era. You think about the 90's. We started out 
still in the traditional large observatory mode. We went to the Faster, Better, 
Cheaper mode to try and go back to that time when the project manager could 
get his arms around the whole thing. The goal was to build smaller spacecraft, 
and have smaller teams building them. There were lots of opportunities in the 
90s to manage projects of that magnitude. The 80 's we had a few large projects, 
and we weren't developing a lot of project managers. In the 90's we went back to 
smaller spacecrafts and built more of them. So why was that a golden age? To 
some extent, there were lots of project management opportunities. There was also 
the ability to learn, and a little bit more tolerance for mistakes than on the very 
large projects. Although the failure of the two Mars missions right in a row set us 
back a little bit. I still think the 90's and the Faster, Better, Cheaper concept, or 
at least the ability to have lots of small spacecrafts, really was a better way to go 
than putting all our money into a few large observatories. And I think it trained 
people, it was more fun, and people were able to be more creative. 


ASK: If you look at those two eras, the 60s and the 90s, do you find any differ- 
ences in the project managers themselves? 


Rothenberg: Well, people are still people. The big difference to me is in the 
automated tools today that project managers have at their disposal. Just take 
email. Years ago communication was slow; it required paper to be circulated. The 
tools for reproducing things, the analytical tools that people had to use, all of 
these things were far more labor-intensive years ago, far more cumbersome. 
Today, we can do more with less people mainly because we've other ways of com- 
municating. Management practices I think are the same, and in fact one of the 
things we have to re learn periodically is some of the practices, the discipline, 
that is, the project management discipline. Take monthly reviews, for instance. 
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Spacewalks like the one shown here were required on the first servicing mis- 
sion of the Hubble Space Telescope. Joseph Rothenberg is widely recognized 
in the Aerospace and Space Science community for leading the development 
and execution of the highly successful first Hubble on-orbit servicing mission. 


You want to use them to nurture people, not beat them up. You've got to encour- 
age people to report problems, and deal with them in a constructive way, not a 
punitive way. These are things we have to re learn periodically. 
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ASK: In what way should NASA be focused on developing good project managers? 


u My view, and I’ve had 
this view for a long 
time, is that we must 
excite the next gener- 
ation of children in 
this country to go into 
science and math, to 
stir their imagination. ” 


Rothenberg: Part of it is just the exposure to project management techniques. 
Some of the centers continue to do a very good job on their own in developing 
a pipeline of project managers. I'm most familiar with Goddard, and I think 
they've always done a good job there in grooming the younger people to take on 
project management responsibilities. The same is true of JPL, I think. In the 
human space flights, the very large programs, for lots of reasons, we have not 
developed a large number of people capable of managing those sorts of projects. 
In fact, if I went out to look for one today to replace somebody like Tommy 
Holloway, it would be very, very difficult. The choices are limited. I also think 
that on the human space flight side once we get the Station problems behind us, 
and I think we will, there will be opportunities to start training the next genera- 
tion of project managers to manage those projects. Right now there is not a train- 
ing ground for project managers for the next generation of human space flight 
programs. Part of it is the fact that we haven't had programs. Another part of it 
is we haven't been hiring. We don't have a lot of people, and so there's going to 
be some holes in the pipeline. And I think rebuilding both the technical work- 
force as well as the project management workforce in human space flight is going 
to be a real challenge. 

ASK: What advice do you have for NASA's project managers today? 

Rothenberg: Use every opportunity you have to train the people below you with 
management skills. Don't only have them solving technical problems, but make 
sure they learn how to recognize costs, to recognize cost trends at the contractor, 
and to analyze manpower. Give them a set of management skills that allows them 
to plan something well, to control requirements. Everyone on a project needs to 
understand that the most important thing is controlling requirements. Typically, 
you get a set of requirements in place and some technical guy will dream up a 
better way of doing something. The first question you have to ask is why do I 
need to make it better, and if you absolutely must make it better, how do you get 
the funding for it. I can point to a number of missions where they made things 
better without shoring up the funding. They dipped into the reserves to spend 
money on new requirements that were unfounded and got themselves into trou- 
ble. Somebody who understood the consequences of such things would have 
asked early on why do I need to make it better. 
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ASK: To your mind, what is the biggest challenge facing NASA as an agency? 

Rothenberg: Establishing a vision for the future. We do not have a vision of 
where NASA is heading. We have a space science program that sort of has a road 
map. We have an earth science program that has a road map. These are frag- 
mented things. I could take the space transportation work, and I could put it 
some place else. I could certainly take the space science work and put it under the 
National Science Foundation. I think we need an integrated vision of what 
NASA's role is in society. Everybody has a different view. If we went away, would 
anybody miss us? Certainly it's the role and responsibility of the Administration, 
of which NASA is a part, to provide a vision that's believable, credible, affordable 
and relevant. There are some things one can do to excite the nation. My view, and 
I've had this view for a long time, is that we must excite the next generation of 
children in this country to go into science and math, to stir their imagination. 1 
think we have an obligation to do this, all of us who are involved with NASA, for 
the good of the agency and the country. 
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u On learning to think 
like a project manag- 
er, Stokely talked 
about how she had to 
“unlearn” to think like 
a scientist. ” 


Conference Report: Masters Forum IV, February '02 

by Todd Post 

The purpose of the APPL Masters Forum is to bring together some of the best 
project managers at NASA, as well as those in industry and other government 
agencies, for 2 1/2 days of knowledge sharing. The project managers come eager 
to reflect on their project experiences, to learn new things from one another— and 
to unlearn a few things, too. 

This was the fourth Masters Forum, and the first one held outside Washington, 
DC. Fifty participants from across the country came to Dallas at the American 
Airlines Conference Center, a wonderful facility that was conveniently located by 
the airport and yet still seemed isolated from the rest of the world. Masters 
Forum IV was also the first one held during the winter. Previous Masters Forums 
have been during the summer. Hot, sticky Washington, D.C. in the summer may 
sound unpleasant, but frankly the popularity of earlier Forums is what led to this 
annual event becoming a semiannual one. 


Monday, February 11, 2002 

On the first night, the keynote presentation was by Judy Stokely, a program man- 
ager in the Air Force, who discussed the Advanced Medium Range Air-to-Air 
Missile (AMRAAM) program; however, the most compelling part of her presen- 
tation was about leadership. 


For Stokely, leading is more than just motivating, it's empowering people to be 
leaders themselves. The ones who rise to the challenge in an organization are 
whom she calls the “change agents,” and she had some advice on how to spot 
these people and how to nurture them. "You must find them, trust them, and 
reward them, because your change agents are the most precious resource you have 
as a project or program manager. " 


There were many notable observations in her presentation. For instance, on 
learning to think like a project manager, Stokely talked about how she had to 
"unlearn" to think like a scientist. 


On the subject of metrics, she advised, "Askjing] the people doing the work what 
you should be measuring. Tell people what you want to achieve and ask them 
what should you measure." 

And more about her favorite topic, leadership: "Don't toss out the problem and 
expect the workforce to manage it. Toss out the vision, what we want to achieve, 
and then let people go off and create it." 
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Conference Report: Masters Forum IV, February "02 (cont’d) 



With 40 years of experience at NASA, Marty Davis exemplifies the kind 
of talent there is at the Masters Forums, 


At the outset of the Masters Forum, Alex Laufer told the participants that one of the 
objectives, beyond those mentioned in my first paragraph, is to help participants 
become more reflective practitioners. Stokely seemed to be the quintessential reflec- 
tive practitioner, inspiring us to reflect on ways that we can be better leaders on our 
own projects, and so it seemed fitting that she be the first speaker at this Forum. In 
the evaluations at the end of the Masters Forum, several people pointed to Stokely "s 
presentation as the high point of the whole thing. Maria Littlefield, a project man- 
ager from Kennedy Space Center, remarked, "Judy Stokely was inspirational. She 
was successful in spite of typical government garbage, whicli is hopeful and refresh- 
ing. I wish I could bottle and distribute her sense of duty for her country." 
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Later in the evening, participants teamed up in small groups to participate in a 
fun little "learning activity" organized by Craig Lawrence of the Silicon Valley- 
based design firm IDEO. For those whose day had begun with a flight in anoth- 
er part of the country, it seemed to be just what they needed to inspire a second 
wind. Groups of small teams were given a deck of cards, a large marble, and a roll 
of tape in a container, and were instructed to try and launch the marble from as 
far away as possible so that it landed inside the container. There were several 
ingenious designs, but then what do you expect at a NASA conference? Joseph 
Rothenberg, a retired Associate Administrator at NASA and a guest speaker the 
next night, arrived about the time the teams were ready to go head to head. A 
good thing he recognized some faces. Otherwise he might have thought he had 
stumbled into the wrong conference--or a marbles tournament. 

Tuesday, February 12, 2002 

Among the many virtues of stories, one is how they disentangle contradictions in 
such a remarkably concise way. Some things may well be black-and-white issues, 
but in project life these sorts of distinctions do not always exist. Stories typically 
allow the many hues of gray to show through. 

For instance, Ken Schwer's story about the QuikToms mission demonstrates that 
a story about a catastrophic project failure can also be a success story. Although 
QuikToms was lost at sea, Schwer understood it was his responsibility as the proj- 
ect manager to prevent his team's heartbreak from destroying all that they'd 
accomplished before the launch. What he did in the aftermath transcends the loss 
of the launch vehicle. His presentation opened the conference on Tuesday morn- 
ing, and his story about the QuikToms mission, "Loss and Recovery," appears in 
this issue. 

We also heard presentations by NASA project managers Dennis Grounds (JSC), 
Tim Owen (MSFC), Joan Salute (ARC), Jeff Bauer (DRFC), Lynne Cooper 
(JPL), Julie Pollit (HQ), and Ed Mauldin (ARC). In the evening, Joseph 
Rothenberg spoke about his career with NASA from being a project manager dur- 
ing the Apollo era to retiring as an Associate Administrator for Space Flight in 
charge of Human Exploration and Development of Space a few months earlier. 

February 13, 2002 

The final day of the Masters Forum was over by lunchtime. It was a short day, 
yes, but it was chock full of excitement. Chuck Duff, Procurement Officer out of 
Ames Research Center, opened with a presentation on the relationship of pro- 
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“ Howell has thought 
long and hard about 
planning — maybe 
longer and harder 
than anyone. ” 
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curement to project management. Duff flew in the night before just to give this 
presentation and had to leave immediately after. Believe it or not, he had just had 
surgery! 



Group discussions are some of the most exicting moments at Masters 
Forms. Here a table of participants are engaged in a small group dis- 
cussion that will broaden to include all the tables. These discussions fol- 
low the presentations by the individual speakers and are perfect exam- 
ples of why this is truly a knowledge sharing conference. 

Watching Duff, I couldn't help but be reminded of a wonderful story I'd heard 
about Teddy Roosevelt. Having barely survived an assassination attempt, the bul- 
let still in his breast and his suit soaked in blood, Roosevelt told a crowd who had 
come to hear him speak, "I will give this speech or die! We have since learned 
that Chuck is doing well and showing great signs of a full recovery. We were 
delighted he could make it, but would certainly have understood had he decided 
to cancel under the circumstances. 

Following Duff came Greg Howell. According to most evaluations, this was 
another of the high points of the Forum. Bob Menrad, a project manager at 
Goddard, stated, "All the folks were very good, but this one hit the chord the 
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most for me." Don Margolies, also from Goddard, remarked, "Greg Howell's talk 
was among the highlights of the meeting for me. Thought provoking, radical (in 
my experience) and screaming out for future considerations." 

Howell is an expert on planning, especially as it bears on large construction proj- 
ects, and that was the subject of his presentation "Lean Project Delivery." Howell 
has thought long and hard about planning-maybe longer and harder than any- 
one. He shared with us how his ideas have evolved, and that in itself was fasci- 
nating. Like Stokely, Howell is another exemplary reflective practitioner. Here is 
a man who has spent the better part of his life thinking about why things occur, 
and what is the most likely way to get a desired result on a project. Howell daz- 
zled the audience with graphs and interactive slides to spice up his Powerpoint. It 
reminded me very much of listening to a college professor again--one of the good 
ones--and that image was reinforced afterwards by the number of people sur- 
rounding him, unwilling to let him go without bending his ear. 

After Howell's presentation there were some remarks by a handful of guests out- 
side of NASA regarding what they'd heard over the past 2 1/2 days and how it 
compared to project life in their domains. Irv Kieback, a project manager from 
Proctor and Gamble, put it best: "This was a great experience. It helped me to see 
how other organizations are dealing with the same problems, and through stories 
I can go utilize the knowledge." 

All that was left then was to lock up the room, head to lunch, and say our 
farewells. Many seemed to think this was the best Masters Forum yet. Indeed 
there were a rich variety of presentations and some exceptional discussions by the 
small and large groups. All I can say is keep up the good work APPL. 

Talk with you next time about Master's Forum V at Tysons Corner in August '02. 
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Letters 


We received the following email in response to Dr. Owen Gadeken s story "Activation 
Energy " in our last issue. 

The short but to the point article by Dr. Owen Gadeken brought home some- 
thing I have tried to push for all my life: Team + Work (on the team) = 
Teamwork. I have gone even as far as saying that there is a new 4 -letter word in 
today's vocabulary: W.O.R.K 

The article by Dr. Owen Gadeken begins with this exact problem: Concern for 
"moving up," rather than working toward the objectives of the project at hand. 
Another problem that wasn't pointed out has to do with "Leader and leadership." 
I do not view "being a leader" as "being in charge." Unless everyone accepts that 
everyone is a leader in some way or another, that everyone must respect each other's 
leadership capabilities, AND that the profile of everyone involved in a team FITS, 
there would only be room for "managing projects," or "conflict resolution." 

In short, I believe in Teams, Teamwork, and Project Management as long as a 
conflict prevention plan is in place. 

Truly yours, 

Miguel A. Prieto 
Oakland Park, Florida 


And we are always glad to receive emails like the one below. 

Hi! I am a Project Manager with Siemens Transportation Systems in Cedar 
Rapids, IA. I just wanted to write you to say thanks! I absolutely love reading 
ASK magazine, and I find it to be one of the most interesting reads out there 
today on Project Management. I often go to back through the older ASK issues 
looking for new PM techniques, or tools. The short story approach is excellent, 
as are the lessons learned at the end of each story. I have my comrades here at the 
office reading it now as well. Thank you and keep up the good work! 

Regards, Shawn Aucutt 

P.S. It still blows my mind that this is a free resource.... 


Thanks to all our readers for their support. We love hearing from you! 
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Review Board 



John Brunson (MSFC) 

John Brunson is currently assigned to the Systems Management Office with the 
Marshall Space Flight Center. His career in the space industry began in 1980 as 
a technician working on the first Space Station. 



Hector Delgado (KSC) 

Hector Delgado is Division Chief of Process Tools and Techniques in the Safety, 
Health and Independent Assessment Directorate at Kennedy Space Center. He 
has received many honors and awards including the NASA Exceptional Service 
medal, the Silver Snoopy Award and various Achievement Awards 



Dr. Michael Hecht (JPL) 

Michael Hecht has been a member of the Jet Propulsion Laboratory staff since 
1982. He is currently Project Manager and a co-investigator for the Mars 
Environmental Compatibility Assessment project. He received his Ph.D from 
Stanford University in 1982 and holds 7 patents, 24 NASA Tech briefs, and has 
published extensively in both surface science and planetary science literature. 
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Jody Zall Kusek (World Bank) 

Jody Hall Kusek Is a Senior Evaluation Officer at the World Bank. She is cur- 
rently involved in supporting the efforts of seven governments to move to a focus 
of performance-based management. She has spent many years in the area of pub- 
lic sector reform, serving the Vice President of the United States, the U.S. 
Secretary of the Interior and the U.S. Secretary of Energy in the areas of Strategic 
Planning and Performance Management 



Don Margolies (GSFC) 

Don Margolies is Project Manager for the Full-Sky Astrometric Mapping 
Explorer (FAME), and Observatory Manager for the Microwave Anisotrophy 
Probe Mission (MAP). Previously, he was Project manager for the Advanced 
Composition Explorer (ACE) mission, launched in 1997. 



Joan Salute (ARC) 

Joan Salute is the Associate Director of Aerospace at Ames Research Center. She 
has managed many NASA projects including those involving flight testing of 
thermal protection materials, commercial technology, commercial applications of 
remote sensing, and remote sensing science projects. 
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Charlie Stegemoeller (JSC) 

Charlie Stegemoeller is currently Manager for Human Space Life Sciences 
Programs Office at Johnson Space Center, responsible for the organization and 
direction of the Human Exploration and Development in Space Enterprise Lead 
Center programs for Biomedical Research and Countermeasure, Advanced 
Human Support Technology, and the Space Medicine crosscutting function. 



Hugh Woodward (PMI) 

Hugh Woodward served as the Chairman of the Project Management Institute 
(PMI) for consecutive terms in 2000 and 2001. He was elected to the Board of 
Directors in 1996, and before being elected as the Chair, served terms as Vice 
Chair and in several other key leadership roles. He is a Program Manager for 
Global Business Services with the Procter & Gamble Company. 
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